insightwatchのセキュリティチェックでオールグリーンを目指す（その3: CISベンチマーク モニタリング編）
オペレーション部 江口です。今日で入社ちょうど1ヶ月を迎えました。早いものですね。 今のところブログの投稿は週一度以上のペースでやれているので、今後もこのペースで続けていきたいものです。
さて、「insightwatchのセキュリティチェックでオールグリーンを目指す」シリーズの第3回です。
第1回：
第2回：
今回は「CIS 3. Monitoring」の対処を行なっていきます。
最初のチェック結果
このパートの最初の結果は以下の通りです。14項目中注意5・重要9の指摘がありました。「正常」だった項目が0!ということで結果が真っ赤っ赤です。
道のり長いな・・・と思いましたが、実は速攻で対処できました。以下その解説です。
指摘事項への対処
この「CIS 3. Monitoring」の要件は以下のように、各種問題についてのアラームの設定となります。 具体的には、CloudTrailの情報をもとに、それを受け取るCloudWatch側にアラームを設定する形です。
- 3.1 許可されていないAPIコールに対して、アラーム通知設定されていること
- 3.2 MFAなしでのAWSマネージメントコンソールログインに対して、アラーム通知設定されていること
- 3.3 rootアカウントの利用に対して、アラーム通知設定されていること
- 3.4 IAMポリシーの変更に対して、アラーム通知設定されていること
- 3.5 CloudTrail設定の変更に対して、アラーム通知設定されていること
- 3.6 AWSマネージメントコンソールのログイン失敗に対して、アラーム通知設定されていること
- 3.7 KMSマスターキーの無効化またはスケジュール削除に対して、アラーム通知設定されていること
- 3.8 S3バケットポリシー変更に対して、アラーム通知設定されていること
- 3.9 AWS Config変更に対して、アラーム通知設定されていること
- 3.10 セキュリティグループ変更に対して、アラーム通知設定されていること
- 3.11 ネットワークACL変更に対して、アラーム通知設定されていること
- 3.12 インターネットゲートウェイ変更に対して、アラーム通知設定されていること
- 3.13 ルートテーブル変更に対して、アラーム通知設定されていること
- 3.14 VPC変更に対して、アラーム通知設定されていること
なかなかのボリュームですが、なんとクラスメソッドメンバーズご利用のお客様にはこれらの設定を一気に行うCloudFormationテンプレートが提供されているのです。すごい！便利！加入しなきゃ！（ダイマ）
このテンプレートの利用の仕方については下記insightwatchユーザーガイドに記載されています。
CIS 3 Monitoringに関する設定（クラスメソッドメンバーズ限定）
ということで、これを利用してデプロイを行いました。
以下、実行に当たっての注意点・補足です。
- チェック結果では各要件に対して全リージョンで設定が必要のように見えます（スクリーンショットを撮り忘れましたが、対応が必要な箇所として全リージョンがリストされます）。ただ、前掲のinsightwatchユーザーガイドでも説明されていますが、クラスメソッドメンバーズをご利用されている場合は全リージョン対応のCloudTrailを東京リージョンに作成しています。このため、東京リージョンでCloudFormationテンプレートのデプロイを行えば良いです。前回使用したCloudFormation StackSetsを利用する必要はありません。
-
テンプレートでIAMロールの作成、LambdaやSNSの作成、CloudWatchの設定追加等を行いますので、CloudFormationを実行するIAMロールにはこれらの適切な権限が必要です。私の環境の場合、普段コンソール操作に利用しているユーザについてはCIS1.X対応（参照：第一回）の際にIAMロール作成の権限を削除しているので、適切な権限を持つIAMロールを別途用意しました。
ハマったこと
このCloudFormationテンプレートのデプロイ直後、再度insightwatchでのチェックを行なって見ると、確かにCIS 3.Xの指摘は全てクリアしました。すばらしい。
しかし、結果を確認すると、前回（第二回）解消したはずの「CIS 2.8 KMSマスターキーがローテーション設定されていること」の指摘が再発していました。
指摘されているKMSのキーを確認すると、これはAWS側の管理する（＝AWSマネージド型）Lambdaがデフォルトで環境変数の暗号化に使用するキーでした。 CloudFormationテンプレートでLambdaをデプロイした際、自動的に作成されたもののようです。
しかしAWSマネージド型キーはローテーション設定をユーザ側では変えられないはず。
これはこちらの対処の仕様がない、詰んだのでは・・・と思ったのですが、一つ疑問が湧きました。
というのも、私の環境でAWSマネージド型のキーは他にもいくつか以前に作成したものが存在します。
けれども指摘されているのはこの新しく作成されたLambda用のキーだけ。
なぜだろう、と思って、以下のようなキーのローテーション設定を確認するコマンドを投げてみました。
aws kms get-key-rotation-status --key-id [Key ID]
Lambda用のキーは確かにKeyRotationEnabledの値がfalse、すなわちローテーションされていない、という結果が返ってきます。
$ aws kms get-key-rotation-status --key-id XXXXXX
{
"KeyRotationEnabled": false
}
しかし他のAWSマネージド型のキーの設定を同じコマンドで調べてみると、KeyRotationEnabledの値としてtrueが返ってきました。
・・・これ、もしかして時間が経つと勝手にローテーションが有効になるのか？
というわけで、一晩おいて見たところ・・・
Lambda用のキーでもローテーションが有効になってました。
改めてinsightwatchでチェックすると、無事CIS2.8の指摘も消えていました。
なかなか奥が深い（？）ですね・・・
ここまでの結果
というわけで若干トラブルはありましたが、ともかくここまでの対処で、「CIS 3. Monitoring」の結果はすべて「正常」となりました。
全体の指摘数は下記の通り。注意2・重要17、指摘の合計は19個となりました。だいぶ減ってきましたね！
推移をグラフにすると以下のような感じです。
このペースなら後2、3回で終わりそうだけども、はたしてそううまく行くかどうか。まあ頑張りたいと思います。
以上、「insightwatchのセキュリティチェックでオールグリーンを目指す」シリーズの第3回でした。
